Best practice guidelines

ProtectToolkit-C can be used to add cryptographic services to any application requiring such services in a standardized way. Cryptographic services are required where security policy exists, and must be enforced to the fullest possible extent by state of the art existing technology. Currently, cryptographic methods are the only way to assure authenticity, confidentiality and integrity to levels that can be mathematically shown to resist all known attacks for the foreseeable future.

Simplicity is another essential goal since complex systems are extremely difficult to analyze to an extent where all weakness can be found or shown not to exist to a level that is practicable. ProtectToolkit-C is a simple and low-level key management and cryptographic service provider and its simplicity should allow it to be used easily to provide the necessary level of cryptographic service.

There are many independent, and sometimes conflicting, goals in the development life cycle of secure products, so this document shall outline the best approach to the use of ProtectToolkit-C, always keeping these goals in mind. Above all, the developer should always strive to keep implementation simple.

The remainder of this document assumes a basic level of understanding of the ProtectToolkit-C product and the PKCS#11 (Cryptoki) system. It refers to the PKCS#11 device as a security module and this may be a stand-alone appliance or adapter-based PKCS#11 security module.

This chapter contains the following sections:

• Introduction

• Application security

• Application usability

• Performance

• Capacity

• Setup and configuration

• Maintainability

• Debugging

• Interoperability

• Programming in FIPS Mode

• Key management

• Hierarchical deterministic wallets in ProtectToolkit

Introduction

The best place to start building a ProtectToolkit-C application is with the sample applications that demonstrate how the ProtectToolkit-C system should be initialized and used to perform various cryptographic operations. Although the samples vary in complexity, they are all real working ProtectToolkit-C utilities and cover all ProtectToolkit-C services.

System security depends mainly on confidentiality, authentication, and access control.

Confidentiality

Confidentiality is critical when data must exist or be transferred through an environment where it may be vulnerable to inspection by an unauthorized person, and damages to the owner of the data may result from such inspection. The best way to protect confidential data is to encrypt it. Examples of confidential information include corporate or personal data, and cryptographic keys.

Integrity/authentication

Integrity requires that no unauthorized person can alter data without detection. Integrity can be assured by using message authentication codes (MAC), a cryptographic digest of the message that requires knowledge of a secret key.

Access control

Access to certain objects must be restricted to reliable people, or circumstances in which misuse can be easily detected . Access control demands accountability from those who interact with the data. It requires users to be authenticated before access is granted. There are many methods of user authentication.

Getting to know ProtectToolkit-C

To become proficient at ProtectToolkit-C development, you must understand PKCS#11 and basic security and cryptographic principles. The entire PKCS (Public Key Cryptographic Standard) suite of standards is relevant, since PKCS#11 employs elements of most of the other PKCS standards. All the PKCS standard documentation can be found online.

You should also refer to PKCS#11 command reference, which details some of the many differences between the PKCS#11 standard and ProtectToolkit-C.

The sample PKCS#11 application code included in the SDK installation is another excellent starting point for getting to know ProtectToolkit-C. These applications can be compiled and inspected, or used directly for commercial PKCS#11 applications.